| PHP팁 게시판 |
|
[1] |
 |
등록일:2007-11-26 16:19:14  (0%)
작성자:
제목:[함수] 다른 서버, 다른 도메인간 세션 공유 방법 1차 개선 |
|
안녕하세요...바로 밑에서 세션 공유에 대한 글을 올렸던 TarauS입니다.
제가 올렸던 글에 대해서 많은 분들이 좋은 의견들을 남겨 주셔서 그 글을 참고하여
보안부분을 조금 더 강화한 소스를 다시 올립니다.
달라진 점이라면 그전에는 세션키만을 전송하였기에 세션키만 알아내면 뚫을 수 있는 취약점이 있었으나 이번에는 세션키를 검증할 수 있는 암호화된 키를 함께 체크합니다.
암호화된 키는 사용자가 고유하게 가지는 값들을 암호화 한 값으로 따로 전송할 필요는 없습니다.(사용자의 환경값이나 아이피값을 가지고 만드는 것이기 때문에 한 사용자가 계속 사용중이라면 변하지 않을테니까요^^)
결론적으로 세션키는 예전처럼 iframe를 이용해서 전송하고 그 대신 DB와의 쿼리 부분에 사용자키도 함께 넣어 체크하도록 한 것입니다.
그리고 또한 레퍼러 및 세션키를 받아서 설정하는 파일명도 함께 체크하도록 하여 조금이라도 보안적으로 강력해지도록 노력하였습니다.
이번 수정된 소스를 보시고 또 여러 의견 남겨 주시기 바랍니다.
아~ 그리고...사용자키를 암호화하는 함수는 넣지 않았습니다... 이 부분은 여러분들이 찾아서 넣으시기 바랍니다.^^
설정에 관련된 것은 밑의 게시물을 열어서 보시기 바랍니다. 참고만 하시고 session.inc 파일의 소스는 지금 올린 것을 사용하세요.
http://www.phpschool.com/bbs2/inc_view.html?id=8923&code=tnt2&start=0&mode=&field=&operator=&period=&category_id=&s_que=
############## session.inc 파일 ###################################################
<?
header('P3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE"');
/* ------------------------------------------------------------------------
Table Scheme
CREATE TABLE sessions (
session_key char(32) not null,
session_expiry int(11) unsigned not null,
session_value text not null,
session_check varchar(250) not null,
PRIMARY KEY (session_key)
);
*/
#### DB 관련설정
$Cfg_DB_Host = "db_host";
$Cfg_DB_User = "db_user";
$Cfg_DB_Pass = "db_pass";
$Cfg_DB_Name = "db_name";
#### 쿠키 관련 설정
$Cfg_Cookie_Domain = ".aaa.com";
#### 보안 관련 설정
## 상대편 서버에서 현재 서버의 link.php 파일을 아이프레임으로 호출하는 파일
$Cfg_Http_Referer = "http://www.bbb.com/member/login_process.php";
## 현재 서버에서 상대편 서버로부터 넘어오는 세션키를 받는 파일
$Cfg_Php_Self = "/member/link.php";
#### 세션 관련 기본 설정
$SESS_DBH = "";
$SESS_LIFE = get_cfg_var("session.gc_maxlifetime");
#### 세션키의 유효성을 체크하기 위한 사용자 키
#### 사용자 키는 사용자가 고유하게 가지는 값들을 이용하여 만들어주면 됨
## 서버키를 설정 (이 값은 아무것이나 정하시면 됩니다.)
$SERVER_KEY = "~1234567890";
## 사용자의 접속 환경
$USER_AGENT = $_SERVER["HTTP_USER_AGENT"];
## 사용자의 접속 아이피
$USER_ADDR = $_SERVER["REMOTE_ADDR"];
## 사용자 키 (각각의 정보를 이용한 조합은 여러분들이 직접 정하세요. 여기서 보여드리는 것은 예시입니다.)
$USER_KEY = $USER_AGENT."||".$USER_ADDR."||".$SERVER_KEY;
#### 암호화 함수(유일한 암호화 함수를 직접 제작함)
function encrypt($key) {
## 이부분에 암호화 루틴을 넣으면 됨 ##
}
#### 암호화 함수를 통해 인코딩된 사용자 키 값
$ENCODE_KEY = encrypt($USER_KEY);
function sess_open($save_path, $session_name){
global $SESS_DBH,$Cfg_DB_Host,$Cfg_DB_User,$Cfg_DB_Pass,$Cfg_DB_Name;
$SESS_DBH = mysql_pconnect($Cfg_DB_Host,$Cfg_DB_User,$Cfg_DB_Pass) or die("SQL 서버에 접속할 수 없습니다.");
mysql_select_db($Cfg_DB_Name, $SESS_DBH) or die("SQL 서버에 접속할 수 없습니다.");
return true;
}
function sess_close(){
return true;
}
function sess_read($key){
global $SESS_DBH, $SESS_LIFE,$ENCODE_KEY;
$qry = "SELECT session_value FROM sessions WHERE session_key = '$key' AND session_check='$ENCODE_KEY' and session_expiry > " . time();
$qid = mysql_query($qry, $SESS_DBH);
if (list($value) = mysql_fetch_row($qid)) {
return $value;
}
return false;
}
function sess_write($key, $val){
global $SESS_DBH, $SESS_LIFE, $ENCODE_KEY;
$expiry = time() + $SESS_LIFE;
$value = addslashes($val);
$qry = "INSERT INTO sessions (session_key,session_expiry,session_value,session_check) VALUES ('$key', $expiry, '$value', '$ENCODE_KEY')";
$qid = mysql_query($qry, $SESS_DBH);
if (! $qid) {
$qry = "UPDATE sessions SET session_expiry = $expiry, session_value = '$value' WHERE session_key = '$key' AND session_check='$ENCODE_KEY' AND session_expiry > " . time();
$qid = mysql_query($qry, $SESS_DBH);
}
return $qid;
}
function sess_destroy($key){
global $SESS_DBH,$USER_KEY;
$qry = "DELETE FROM sessions WHERE session_key = '$key' AND session_check='$ENCODE_KEY'";
$qid = mysql_query($qry, $SESS_DBH);
return $qid;
}
function sess_gc($maxlifetime){
global $SESS_DBH;
$qry = "DELETE FROM sessions WHERE session_expiry < " . time();
$qid = mysql_query($qry, $SESS_DBH);
return mysql_affected_rows($SESS_DBH);
}
#### 세션키를 설정하는 함수
function set_session_id($SESSID){
global $HTTP_REFERER, $PHP_SELF;
## 레퍼러 및 현재 파일명을 함께 체크해서 제대로 된 요청일 때만 세션키를 설정
if($SESSID&&$HTTP_REFERER==$Cfg_Http_Referer&&$PHP_SELF==$Cfg_Php_Self) @session_id($SESSID);
}
set_session_id($SESSID);
session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc");
session_set_cookie_params(0, "/", $Cfg_Cookie_Domain);
ini_set('session.cache_limiter' ,'nocache, must-revalidate-revalidate');
session_start();
?>
query 03-04-25 19:20
function sess_close(){
return true;
}
에서 mysql_close() 안해주는 이유는 머죠?
돼는김에 중복로긴 방지도 하면 정말 좋게따
다른 아이피이면 로긴 자체가 안돼게...
function sess_close(){
return true;
}
에서 mysql_close() 안해주는 이유는 머죠?
돼는김에 중복로긴 방지도 하면 정말 좋게따
다른 아이피이면 로긴 자체가 안돼게...
query 03-04-25 19:20
수고하셨습니다 ^^
수고하셨습니다 ^^
궁금 03-04-26 02:41
암호화라는게 결국 서버단에서는 사용자가 주는 정보가
키가 되므로 여러가지 짬뽕해도 사용자 키만 알아내면
뚫리지 않을까요?
암호화라는게 결국 서버단에서는 사용자가 주는 정보가
키가 되므로 여러가지 짬뽕해도 사용자 키만 알아내면
뚫리지 않을까요?
TarauS 03-04-26 09:36
참고//
세션을 쓸 때 쿠키를 전혀 사용하지 않을 수는 없습니다.세션을 시작하면 기본적으로 세션키가 쿠키로 등록이됩니다.
글구 좀 더 보안에 신경을 쓴다면 세션키를 암호화할 수도 있긴 한데 지금 사용하는 방법과 별 차이가 없다고 봅니다. 왜냐면 지금 생각한 방법도 세션키와, 사용자 환경 정보와 서버키를 모두 알아야지만 알 수 있기 때문이죠..
여기다가 환경을 register_globals = off로 셋팅하고 넘어오는 값들을 체크하면 더 좋구여...
궁금//
그럴 가능성도 있긴합니다. 여기 글에는 올리지 않았지만 그럴 경우에 대비해서 서비키를 따로 두고 있습니다. 이 세션파일을 셋팅하면서 설정하는 변수 중에 서버키 변수를 따로 설정하고 이 값을 유저키랑 조합한 다음에 그걸 암호화하는 것이죠. 그렇게 된다면 뚫기가 좀더 어려워 지겠죠..
참고//
세션을 쓸 때 쿠키를 전혀 사용하지 않을 수는 없습니다.세션을 시작하면 기본적으로 세션키가 쿠키로 등록이됩니다.
글구 좀 더 보안에 신경을 쓴다면 세션키를 암호화할 수도 있긴 한데 지금 사용하는 방법과 별 차이가 없다고 봅니다. 왜냐면 지금 생각한 방법도 세션키와, 사용자 환경 정보와 서버키를 모두 알아야지만 알 수 있기 때문이죠..
여기다가 환경을 register_globals = off로 셋팅하고 넘어오는 값들을 체크하면 더 좋구여...
궁금//
그럴 가능성도 있긴합니다. 여기 글에는 올리지 않았지만 그럴 경우에 대비해서 서비키를 따로 두고 있습니다. 이 세션파일을 셋팅하면서 설정하는 변수 중에 서버키 변수를 따로 설정하고 이 값을 유저키랑 조합한 다음에 그걸 암호화하는 것이죠. 그렇게 된다면 뚫기가 좀더 어려워 지겠죠..
TarauS 03-04-26 09:38
query//
중복로긴 기능은 그리 어렵지 않을 것이라 생각됩니다. id 필드와 ip 필드를 추가해서 id 정보와 ip정보를 담고 로그인 체크 부분에서 이 값들을 비교하면 쉽게 구현 가능하리라 봅니다. 이 부분은 이걸 이용하시는 분들의 숙제로 남겨드리겠습니다.
query//
중복로긴 기능은 그리 어렵지 않을 것이라 생각됩니다. id 필드와 ip 필드를 추가해서 id 정보와 ip정보를 담고 로그인 체크 부분에서 이 값들을 비교하면 쉽게 구현 가능하리라 봅니다. 이 부분은 이걸 이용하시는 분들의 숙제로 남겨드리겠습니다.
wawoo 03-04-26 12:44
보안을 위한 거라면
http_referer 를 이용해서 요청이 들어온 페이지의 주소를 이용해서 제한을 하고 HTTP 프로토콜 방식으로 내부적으로 키를 날려서 데이터베이스에 인증키를 등록하고 그걸 체크하면.....
잠깐 구상해 봤습니다.
보안을 위한 거라면
http_referer 를 이용해서 요청이 들어온 페이지의 주소를 이용해서 제한을 하고 HTTP 프로토콜 방식으로 내부적으로 키를 날려서 데이터베이스에 인증키를 등록하고 그걸 체크하면.....
잠깐 구상해 봤습니다.
TarauS 03-04-26 13:14
wawoo//
현재 그런식으로 구성이 되어있습니다. 위에 소스를 보면 HTTP_REFERER을 체크하고 있고 또한 받아들이는 파일이름도 체크하고 있습니다.
그리고 기본으로 세션키를 이용하면서 검증용키를 하나 더 만들어서 데이터베이스에서 쿼리하여 결과를 얻어내는 방식입니다.
wawoo//
현재 그런식으로 구성이 되어있습니다. 위에 소스를 보면 HTTP_REFERER을 체크하고 있고 또한 받아들이는 파일이름도 체크하고 있습니다.
그리고 기본으로 세션키를 이용하면서 검증용키를 하나 더 만들어서 데이터베이스에서 쿼리하여 결과를 얻어내는 방식입니다.
Fencer 03-04-26 14:00
>>> wawoo
사실 referer는 작정한 사람에게는 있으나 마나합니다.
어차피 세션키를 먹으려고 작정한 사람은
HTTP Header를 조작하려 하는 셈이고,
그 때 Referer는 아무런 가치가 없죠.
아주 아주 조금 귀찮아질 뿐. ㅡㅡ;
(실제로 저도 장난할 때 브라우저가 보내는
헤더 정보 100% 똑같이 넘깁니다.)
중요한 것은 모든 키와 환경 정보를 알아도
권한을 획득하지 못 하도록 하는 것이죠.
공개키가 강력한 게 바로 그런 거 아니겠습니까.
>>> wawoo
사실 referer는 작정한 사람에게는 있으나 마나합니다.
어차피 세션키를 먹으려고 작정한 사람은
HTTP Header를 조작하려 하는 셈이고,
그 때 Referer는 아무런 가치가 없죠.
아주 아주 조금 귀찮아질 뿐. ㅡㅡ;
(실제로 저도 장난할 때 브라우저가 보내는
헤더 정보 100% 똑같이 넘깁니다.)
중요한 것은 모든 키와 환경 정보를 알아도
권한을 획득하지 못 하도록 하는 것이죠.
공개키가 강력한 게 바로 그런 거 아니겠습니까.
TarauS 03-04-26 19:48
참고//
session_start()함수를 사용하지 않는다면 세션을 전혀 사용할 수 없는 것이겠죠.. 그러면 여기서 예기할 의미가 없어지겠죠?^^
참고//
session_start()함수를 사용하지 않는다면 세션을 전혀 사용할 수 없는 것이겠죠.. 그러면 여기서 예기할 의미가 없어지겠죠?^^
Fencer 03-04-26 21:25
session_start() 한다고 쿠키 굽는 거 아니죠.
php.ini 에서 쿠키를 사용하도록 설정되어 있어야 하거든요.
물론 GET, POST 등으로 넘길 수도 있습니다.
매뉴얼을 보시길.
session_start() 한다고 쿠키 굽는 거 아니죠.
php.ini 에서 쿠키를 사용하도록 설정되어 있어야 하거든요.
물론 GET, POST 등으로 넘길 수도 있습니다.
매뉴얼을 보시길.
~.` 03-04-26 22:42
ini_set을 참고..
ini_set을 참고..
Fencer 03-04-27 00:04
>>> 참고
그런 의미가 아니죠.
PHP 자체의 세션은 session_start()를 하지 않을 경우
사용할 수 없는 게 맞습니다. 맞고요.
사실 세션 비스무리한 걸 자체적으로 개발해서 한다한들
HTTP 1.1 한계 내에서 PHP 세션보다 나아질 게 별로 없죠.
HTTPS를 써야. ㅋㅋ;;;
>>> 참고
그런 의미가 아니죠.
PHP 자체의 세션은 session_start()를 하지 않을 경우
사용할 수 없는 게 맞습니다. 맞고요.
사실 세션 비스무리한 걸 자체적으로 개발해서 한다한들
HTTP 1.1 한계 내에서 PHP 세션보다 나아질 게 별로 없죠.
HTTPS를 써야. ㅋㅋ;;;
TarauS 03-04-27 00:58
세션을 전혀 사용할 수 없다는 것은 제가 잘못 말씀드린것 같습니다. 지금 제가 구현한 방법에서는 세션키를 기준으로해서 db에 쿼리를 날려서 읽어오고 db에 저장하는 것이기에 세션키가 필요하므로 그렇게 말씀드렸던 것입니다.
세션키를 사용해서 이런 식으로 구현하는 것이 괜찮은 방법인거 같아 만들게 되었던거구요...
세션을 전혀 사용할 수 없다는 것은 제가 잘못 말씀드린것 같습니다. 지금 제가 구현한 방법에서는 세션키를 기준으로해서 db에 쿼리를 날려서 읽어오고 db에 저장하는 것이기에 세션키가 필요하므로 그렇게 말씀드렸던 것입니다.
세션키를 사용해서 이런 식으로 구현하는 것이 괜찮은 방법인거 같아 만들게 되었던거구요...
TarauS 03-04-27 01:07
위에서 궁금님이 제시했던 서버키란 것을 다시 한번 생각해 보았는데 제가 잘못 생각하고 있었습니다. 서버키란것을 함께 만들어 암호화한 것을 비교할려구 했는데 어짜피 사용자 환경과 아이피 같은 것을 안다면 이것만 가지고 암호화를 하나 서버키를 하나더 추가해서 암호화 하나 별 차이가 없을 것 같네염..
왜냐면 사용자키와 서버키를 조합해서 만들어진 키를 암호화할 때 서버키는 고정된것이고 사용자키를 사용자 환경과 아이피만 알면 만들 수 있기에 암호화된 키도 만드는게 가능하겠죠..
이 부분에 대해서도 조금더 생각해 보고서 보완할 방법을 올리도록 하겠습니다.
위에서 궁금님이 제시했던 서버키란 것을 다시 한번 생각해 보았는데 제가 잘못 생각하고 있었습니다. 서버키란것을 함께 만들어 암호화한 것을 비교할려구 했는데 어짜피 사용자 환경과 아이피 같은 것을 안다면 이것만 가지고 암호화를 하나 서버키를 하나더 추가해서 암호화 하나 별 차이가 없을 것 같네염..
왜냐면 사용자키와 서버키를 조합해서 만들어진 키를 암호화할 때 서버키는 고정된것이고 사용자키를 사용자 환경과 아이피만 알면 만들 수 있기에 암호화된 키도 만드는게 가능하겠죠..
이 부분에 대해서도 조금더 생각해 보고서 보완할 방법을 올리도록 하겠습니다.
Fencer 03-04-27 01:45
>>> 참고
님은 잘 알지 못 하면서 남을 깔아 뭉개는 걸 즐기시나봐요.
\"틀에 박힌 코딩만 한다는 뜻으로 알겠습니다.^^\"
\"님의 수준으로 알겠습니다.\"
고상한 취미를 가지셨네요. ^ ^)b
쿠키를 사용하지 않는 것(GET, POST, ...)과
사용하는 거는 거의 차이가 없습니다.
쿠키는 다른 메서드로 전달해도 될 것을
귀차니즘을 피하기 위해 쓰는 것 뿐입니다.
HTTP 표준 문서 읽어보셨습니까?
HTTP만으로는 아무리 발버둥을 쳐도
키를 만드는 규칙이 밝혀지기만 하면 끝장입니다.
프로토콜 자체의 한계라고 할 수 있죠.
그래서 신용 카드 회사, 은행 등등의 사이트에서는
클라이언트에 보안툴 설치하고 시작하는 겁니다.
아니면 HTTPS로 바꾸든지요.
남에게 아는 척을 하시려면 지식을 좀 더 쌓고 해보세요.
그럼 기쁘게 가르침을 받도록 하지요.
왜 HTTP로는 아무리 잘 만들어봐야 한계가 있고,
HTTPS로 바꾸어야 한다고 하는지도 모르고 말씀하시는 건지.
>>> 참고
님은 잘 알지 못 하면서 남을 깔아 뭉개는 걸 즐기시나봐요.
\"틀에 박힌 코딩만 한다는 뜻으로 알겠습니다.^^\"
\"님의 수준으로 알겠습니다.\"
고상한 취미를 가지셨네요. ^ ^)b
쿠키를 사용하지 않는 것(GET, POST, ...)과
사용하는 거는 거의 차이가 없습니다.
쿠키는 다른 메서드로 전달해도 될 것을
귀차니즘을 피하기 위해 쓰는 것 뿐입니다.
HTTP 표준 문서 읽어보셨습니까?
HTTP만으로는 아무리 발버둥을 쳐도
키를 만드는 규칙이 밝혀지기만 하면 끝장입니다.
프로토콜 자체의 한계라고 할 수 있죠.
그래서 신용 카드 회사, 은행 등등의 사이트에서는
클라이언트에 보안툴 설치하고 시작하는 겁니다.
아니면 HTTPS로 바꾸든지요.
남에게 아는 척을 하시려면 지식을 좀 더 쌓고 해보세요.
그럼 기쁘게 가르침을 받도록 하지요.
왜 HTTP로는 아무리 잘 만들어봐야 한계가 있고,
HTTPS로 바꾸어야 한다고 하는지도 모르고 말씀하시는 건지.
Fencer 03-04-27 01:53
IP까지 속이는 세상입니다.
안전하다고 생각하는 거 자체가 잘못된 거죠.
불완전하다는 걸 알고 있어야합니다.
IP까지 속이는 세상입니다.
안전하다고 생각하는 거 자체가 잘못된 거죠.
불완전하다는 걸 알고 있어야합니다.
0172 03-04-27 02:13
이건 제 생각일 뿐인데요...만약에 사용자키를 만드는 규칙을 알고 있더라도 똑같은 사용자키를 만드는건 어려운거 아닌가요?
예를 들어서 crypt 함수 같은 경우는 똑같은 문자를 가지고도 매번 실행할때 마다 다른 값이 나오지 않나요...?
여기다가 ip address, 브바루저 정보, microtime 등등을 같이 조합해서 암호화 한다면 더욱 그럴것 같은데...
이건 제 생각일 뿐인데요...만약에 사용자키를 만드는 규칙을 알고 있더라도 똑같은 사용자키를 만드는건 어려운거 아닌가요?
예를 들어서 crypt 함수 같은 경우는 똑같은 문자를 가지고도 매번 실행할때 마다 다른 값이 나오지 않나요...?
여기다가 ip address, 브바루저 정보, microtime 등등을 같이 조합해서 암호화 한다면 더욱 그럴것 같은데...
0172 03-04-27 02:23
역시 생각일뿐인데... 세션키를 사용하지 않고도 사용자 인증을 할 수 있을것 같습니다. 올바르게 로그인한 사용자에게 유일한 인증키를 부여하고 db에 저장한 후 이 인증키로 사용자를 확인하면 되지 않을까 싶은데... 물론 인증키는 같은 문자로 암호화해도 절대 같아지지 않는 방법으로 만들어서말이죠...
역시 생각일뿐인데... 세션키를 사용하지 않고도 사용자 인증을 할 수 있을것 같습니다. 올바르게 로그인한 사용자에게 유일한 인증키를 부여하고 db에 저장한 후 이 인증키로 사용자를 확인하면 되지 않을까 싶은데... 물론 인증키는 같은 문자로 암호화해도 절대 같아지지 않는 방법으로 만들어서말이죠...
Fencer 03-04-27 02:32
>>> 0172
\"로그인한 사용자에게 유일한 인증키를 부여한다.\"
이게 바로 세션키가 아니든가요? 6^ ^;;;
세션키가 꼭 md5로 만든 32Bytes 문자열일 필요는 없죠.
절대 겹치지만 않는다면 그냥 int로 해도 돼요.
그리고 몰라서 묻는 건데요...
같은 문자로 암호화해도 매번 다르다면
어떻게 비교를 할 수가 있을까요. ㅡ.ㅡ;;;
아, 그리고 crypt는 salt가 달라져야만
다른 값이 나온다고 알고 있습니다.
>>> 0172
\"로그인한 사용자에게 유일한 인증키를 부여한다.\"
이게 바로 세션키가 아니든가요? 6^ ^;;;
세션키가 꼭 md5로 만든 32Bytes 문자열일 필요는 없죠.
절대 겹치지만 않는다면 그냥 int로 해도 돼요.
그리고 몰라서 묻는 건데요...
같은 문자로 암호화해도 매번 다르다면
어떻게 비교를 할 수가 있을까요. ㅡ.ㅡ;;;
아, 그리고 crypt는 salt가 달라져야만
다른 값이 나온다고 알고 있습니다.
TarauS 03-04-27 03:15
0172//
현재는 사용자키를 비교할 때 똑같은 문자열만 비교합니다.
그러니깐 똑같은 사용자 정보가 들어온다면 암호화된 사용자키도 똑같은 것을 사용해야 한다는 것이죠.
그래야지 사용자가 A사이트에서 B사이트로 이동했을때 같은 사용자키를 가지고 있을 수 있는 것이죠...
(제가 생각하는 사용자키에서는 microtime 같은 값은 이용하지 안습니다. 키를 만들었을때 유일성은 보장할 수 있겠지만 A사이트에 접속했을 때와 B사이트에 접속했을 때 같은 정보를 가지도록 할 수는 없기 때문입니다.그러나 사용자 환경 정보나 IP정보는 사용자가 A 사이트에 접속하든 B사이트에 접속하든 일정하기 때문에 사용하는 것입니다.여기서 microtime같은 값을 쿠키로 설정하거나 전송해 줄 수 있기는 하지만 어짜피 이건 조작의 가능성이 있기에 있으나 마나한 것으로 생각됩니다.)
글구 세션키는 직접 만들어 쓰실 수도 있습니다. 자신이 직접 키를 만든 다음에 session_id(직접 만든 키)와 같이 하면 세션키를 설정할 수 있습니다.
Fencer//
제가 구현한 방법에서는 매번 암호화할 때마다 다른 암호화된키가 생성된다면 비교할 수는 없습니다.
그러나 암호화 함수를 crypt()함수 같은 것을 사용한다면 매번 암호화할 때마다 키가 변경되도록 할 수 있습니다. 또한 비교도 가능하고여...
그러나 어짜피 사용자 환경이나 아이피로 이루어진 사용자키를 가지고 암호화 하는 것이기 때문에 이 사용자키를 조정한다면 어짜피 암호화 자체가 의미가 없을 것 같습니다.
그래서 다른 방법을 생각중에 있습니다.
0172//
현재는 사용자키를 비교할 때 똑같은 문자열만 비교합니다.
그러니깐 똑같은 사용자 정보가 들어온다면 암호화된 사용자키도 똑같은 것을 사용해야 한다는 것이죠.
그래야지 사용자가 A사이트에서 B사이트로 이동했을때 같은 사용자키를 가지고 있을 수 있는 것이죠...
(제가 생각하는 사용자키에서는 microtime 같은 값은 이용하지 안습니다. 키를 만들었을때 유일성은 보장할 수 있겠지만 A사이트에 접속했을 때와 B사이트에 접속했을 때 같은 정보를 가지도록 할 수는 없기 때문입니다.그러나 사용자 환경 정보나 IP정보는 사용자가 A 사이트에 접속하든 B사이트에 접속하든 일정하기 때문에 사용하는 것입니다.여기서 microtime같은 값을 쿠키로 설정하거나 전송해 줄 수 있기는 하지만 어짜피 이건 조작의 가능성이 있기에 있으나 마나한 것으로 생각됩니다.)
글구 세션키는 직접 만들어 쓰실 수도 있습니다. 자신이 직접 키를 만든 다음에 session_id(직접 만든 키)와 같이 하면 세션키를 설정할 수 있습니다.
Fencer//
제가 구현한 방법에서는 매번 암호화할 때마다 다른 암호화된키가 생성된다면 비교할 수는 없습니다.
그러나 암호화 함수를 crypt()함수 같은 것을 사용한다면 매번 암호화할 때마다 키가 변경되도록 할 수 있습니다. 또한 비교도 가능하고여...
그러나 어짜피 사용자 환경이나 아이피로 이루어진 사용자키를 가지고 암호화 하는 것이기 때문에 이 사용자키를 조정한다면 어짜피 암호화 자체가 의미가 없을 것 같습니다.
그래서 다른 방법을 생각중에 있습니다.
전영규 03-04-27 13:51
TarauS 님, 수고 많으십니다.
키를 만들 때 사용자 정보를 이용하는 수도 있지만,
임의의 키를 생성후에 (랜덤..) 그 키를 이용할 수도 있습니다.
랜덤으로 키를 하나 생성후, 서버에 하나 보관하고
클라이언트에 하나 보내주는 것이죠.
다음 요청이 올 때, 그 키가 서버의 키와 같은 키인지 조사하면 됩니다. 여기서 키를 만드는 방법만 유일한 것이면 되고..
님의 소스에서 별로 수정할 부분은 없습니다.
제가 이렇게까지 말하면, 할만한 사람은 다 구현하겠죠 ?
수고 많이 하셨구요, 이제 나머지 작업은 TarauS 님이
공개 안하셔도 괜찮다고 봅니다... ^^
-- jeon.
TarauS 님, 수고 많으십니다.
키를 만들 때 사용자 정보를 이용하는 수도 있지만,
임의의 키를 생성후에 (랜덤..) 그 키를 이용할 수도 있습니다.
랜덤으로 키를 하나 생성후, 서버에 하나 보관하고
클라이언트에 하나 보내주는 것이죠.
다음 요청이 올 때, 그 키가 서버의 키와 같은 키인지 조사하면 됩니다. 여기서 키를 만드는 방법만 유일한 것이면 되고..
님의 소스에서 별로 수정할 부분은 없습니다.
제가 이렇게까지 말하면, 할만한 사람은 다 구현하겠죠 ?
수고 많이 하셨구요, 이제 나머지 작업은 TarauS 님이
공개 안하셔도 괜찮다고 봅니다... ^^
-- jeon.
전영규 03-04-27 13:53
위의 방식은 일종의 \＇비밀키\＇방식의 보안이라고 할 수 있구요.
공개키 방식으로 가면 좋은데 연산량이 장난이 아니고, 굳이 그렇게까지 할 필요도 없습니다.. 특히, 서버대 클라이언트라면 굳이 공개키로 갈 필요도 없구요... 왜냐하면, 서버가 해킹당하지 않는한 비밀키의 조합방법이 노출되지 않을테니까요.
-- jeon.
위의 방식은 일종의 \＇비밀키\＇방식의 보안이라고 할 수 있구요.
공개키 방식으로 가면 좋은데 연산량이 장난이 아니고, 굳이 그렇게까지 할 필요도 없습니다.. 특히, 서버대 클라이언트라면 굳이 공개키로 갈 필요도 없구요... 왜냐하면, 서버가 해킹당하지 않는한 비밀키의 조합방법이 노출되지 않을테니까요.
-- jeon.
전영규 03-04-27 13:57
참... 쓰고보니 키를 그대로 도용하는 경우에 대한 대비를 놓쳤군요... 이는 IP로 구분해도 대부분 충분합니다. (키 자체에 IP정보를 담고 있는게 편하구요.. )
IP를 속이는 단계는 크게 proxy 와 IP헤더의 임의조작으로 가능한데, proxy 는 같은 proxy 단에 사용자가 있어야 가능하니까 이 부분에 대해서만 약간 신경쓰면 되구요.
IP헤더 수정부분은, TCP가 내부 연결을 위해 3-핸드쉐이킹을 하면서 피어를 확인하기 때문에, HTTP상에서의 IP헤더 수정은 불가능합니다..
-- jeon.
참... 쓰고보니 키를 그대로 도용하는 경우에 대한 대비를 놓쳤군요... 이는 IP로 구분해도 대부분 충분합니다. (키 자체에 IP정보를 담고 있는게 편하구요.. )
IP를 속이는 단계는 크게 proxy 와 IP헤더의 임의조작으로 가능한데, proxy 는 같은 proxy 단에 사용자가 있어야 가능하니까 이 부분에 대해서만 약간 신경쓰면 되구요.
IP헤더 수정부분은, TCP가 내부 연결을 위해 3-핸드쉐이킹을 하면서 피어를 확인하기 때문에, HTTP상에서의 IP헤더 수정은 불가능합니다..
-- jeon.
TarauS 03-04-27 14:48
전영규// 격려해 주셔서 고맙습니다...^^
현재 사용자키를 만들 때 아이피 정보도 함께 넣어 키를 만들고 이걸 다시 암호화합니다.이 방법에 보완이 필요한 것인가요?
전영규// 격려해 주셔서 고맙습니다...^^
현재 사용자키를 만들 때 아이피 정보도 함께 넣어 키를 만들고 이걸 다시 암호화합니다.이 방법에 보완이 필요한 것인가요?
Fencer 03-04-27 15:32
>>> TarauS
전영규님이 말씀하신 것은 (전영규님 글에도 나왔듯)
결국 이미 TarauS님이 하신 거랑 마찬가지 방식입니다.
PHP 자체에서 만드는 session_id도 랜덤이죠.
거기다 사용자의 환경 정보와 IP, 서버쪽 키 등을 추가해
단방향 암호화 한번 해주는 게 좋긴 더 좋은데
이미 어느 정도 하셨을 거라는 생각이 듭니다.
저의 경우는 1. session_id 자체에 사용자 환경 정보를 넣어 만들고
2. session_id, 사용자 환경 정보, 서버 키 등등을 넣어 체크용 쿠키를 하나 씁니다.
2가지가 모두 맞아야 정상적인 것으로 인정합니다.
아, 불순한 시도가 있다고 세션 자체를 제거하지는 말아야겠죠.
그럼 정상적으로 사용하던 사람이 곤란해지니까. ㅡㅡ;
>>> TarauS
전영규님이 말씀하신 것은 (전영규님 글에도 나왔듯)
결국 이미 TarauS님이 하신 거랑 마찬가지 방식입니다.
PHP 자체에서 만드는 session_id도 랜덤이죠.
거기다 사용자의 환경 정보와 IP, 서버쪽 키 등을 추가해
단방향 암호화 한번 해주는 게 좋긴 더 좋은데
이미 어느 정도 하셨을 거라는 생각이 듭니다.
저의 경우는 1. session_id 자체에 사용자 환경 정보를 넣어 만들고
2. session_id, 사용자 환경 정보, 서버 키 등등을 넣어 체크용 쿠키를 하나 씁니다.
2가지가 모두 맞아야 정상적인 것으로 인정합니다.
아, 불순한 시도가 있다고 세션 자체를 제거하지는 말아야겠죠.
그럼 정상적으로 사용하던 사람이 곤란해지니까. ㅡㅡ;
전영규 03-04-27 16:29
TarauS님, Fencer 님, 이견이 없습니다. ^^
휴일 잘 보내세요.
-- jeon.
TarauS님, Fencer 님, 이견이 없습니다. ^^
휴일 잘 보내세요.
-- jeon.
굿임다 03-04-27 17:40
이런 기능이 필요했었는데 이렇게 구현해 주시니 정말로 감사드립니다.
이런 기능이 필요했었는데 이렇게 구현해 주시니 정말로 감사드립니다.
TarauS 03-04-28 13:46
참고//
글이란것은 어떻게 쓰느냐에 따라 기분이 나쁠 수도 있고 좋을 수도 있는 것입니다.
님이 남긴 글에 저도 기분이 약간은 상했습니다.
저나 Fencer님이 잘못된 의견을 주장하셨더라도 그것을 삐딱하게 말하는 것 보다는 무엇이 잘못됐는지를 정확히 지적해 주시는게 글을 남긴 우리들이나 다른 분들이 보기에도 좋은 것이죠.
제가 알고 있는 것을 저는 맞다고 믿고 있을 수 있고 나중에 잘못된 것을 알게 되면 그때 또 배워나가는 것이니까요...
참고//
글이란것은 어떻게 쓰느냐에 따라 기분이 나쁠 수도 있고 좋을 수도 있는 것입니다.
님이 남긴 글에 저도 기분이 약간은 상했습니다.
저나 Fencer님이 잘못된 의견을 주장하셨더라도 그것을 삐딱하게 말하는 것 보다는 무엇이 잘못됐는지를 정확히 지적해 주시는게 글을 남긴 우리들이나 다른 분들이 보기에도 좋은 것이죠.
제가 알고 있는 것을 저는 맞다고 믿고 있을 수 있고 나중에 잘못된 것을 알게 되면 그때 또 배워나가는 것이니까요...
깨스 03-04-30 00:17
-----
키를 두개를 만든다는 것은... 비교할 수 있는 키를 하나
더 만든다는 것이군요. 즉 ip 정보나 기타 클라이언트의 유일한
정보를 가지고, 키를 만들고 서버단에서 암호화 하여 확인할 수 있는...
그것이 아니라면. 세션키 값은 이미 유일할테고....
근데 의문점이 생깁니다.
1. 세션키를 왜 쿠키로만 보존할라고 하시나요? URL로 넘기면 안되나요?
2. 두개이상의 서버의 세션을 공유하는데. 하나의 세션키의 보안을 신경쓰는 것과
두개이상의서버로 공유할 세션키를 신경쓰는 것과 차이가 많은가요?
3. 복호화나 암호화 하여 비교 가능한 키를 만든다 하여도.
키가 계속 변하지 않는 이상 무의미하죠?
그렇다면 기존의 세션키와 무슨 차이가 있는거죠?
어느 겝을 두고 변한다면... DB나 연산작업등 system에 부하를 주지않는 선에서 변한다고
하여도. 세션키를 스니핑하여 세션키가 존재하는 동안에 해킹하는 넘을 막을 수 있을라나?
https를 전체적인 시스템에서 쓴다는 것도 문제가 있고...
접속자가 적다면 상관없지만.
로그인시에 패스워드 인증시만 https를 쓰고
인증이나 키타 보안에 필요한 유지성 변수나 자료 객체들은 세션을 이용하되.
접속자가 많고 부하가 심하다면, 쿠키로 구현하는 겁니다.
쿠키로 인증시는 단순하게 값이 있나 없나를 체크하는게 아니라
IP, 시간으로, 클라이언트정보로 로그인시나 특정 시간마다 변할 수 있는... 것을 암호화하여.
세션키 해킹을 예비해 다른 키를 둔다는 것 자체가 제가볼땐 무의미한것 같네요
글고
mysql_pconnect() 하면, 나중에 conn가 꽉 차지 않나요??
참고로... 타라우스는 제가 잘 아는 분인거 같고... 지송하지만 저번글도 보고 비슷한 글을 올렸지만. 글은 시간이 없어 자세히 정독은 못했습니다. 아무래도 제가 논지를 제대로 파악하지 못하고 글을 쓴거 같기도하고.... 여하튼 별 신경 쓰지마세요.
-----
키를 두개를 만든다는 것은... 비교할 수 있는 키를 하나
더 만든다는 것이군요. 즉 ip 정보나 기타 클라이언트의 유일한
정보를 가지고, 키를 만들고 서버단에서 암호화 하여 확인할 수 있는...
그것이 아니라면. 세션키 값은 이미 유일할테고....
근데 의문점이 생깁니다.
1. 세션키를 왜 쿠키로만 보존할라고 하시나요? URL로 넘기면 안되나요?
2. 두개이상의 서버의 세션을 공유하는데. 하나의 세션키의 보안을 신경쓰는 것과
두개이상의서버로 공유할 세션키를 신경쓰는 것과 차이가 많은가요?
3. 복호화나 암호화 하여 비교 가능한 키를 만든다 하여도.
키가 계속 변하지 않는 이상 무의미하죠?
그렇다면 기존의 세션키와 무슨 차이가 있는거죠?
어느 겝을 두고 변한다면... DB나 연산작업등 system에 부하를 주지않는 선에서 변한다고
하여도. 세션키를 스니핑하여 세션키가 존재하는 동안에 해킹하는 넘을 막을 수 있을라나?
https를 전체적인 시스템에서 쓴다는 것도 문제가 있고...
접속자가 적다면 상관없지만.
로그인시에 패스워드 인증시만 https를 쓰고
인증이나 키타 보안에 필요한 유지성 변수나 자료 객체들은 세션을 이용하되.
접속자가 많고 부하가 심하다면, 쿠키로 구현하는 겁니다.
쿠키로 인증시는 단순하게 값이 있나 없나를 체크하는게 아니라
IP, 시간으로, 클라이언트정보로 로그인시나 특정 시간마다 변할 수 있는... 것을 암호화하여.
세션키 해킹을 예비해 다른 키를 둔다는 것 자체가 제가볼땐 무의미한것 같네요
글고
mysql_pconnect() 하면, 나중에 conn가 꽉 차지 않나요??
참고로... 타라우스는 제가 잘 아는 분인거 같고... 지송하지만 저번글도 보고 비슷한 글을 올렸지만. 글은 시간이 없어 자세히 정독은 못했습니다. 아무래도 제가 논지를 제대로 파악하지 못하고 글을 쓴거 같기도하고.... 여하튼 별 신경 쓰지마세요.
TarauS 03-04-30 09:38
깨스//
처음 이 방법을 시도할 때는 보안을 크게 신경쓰지 않은 상황에서 기능 구현에 초점을 두고서 만들었습니다.
그러나 첫번째 글을 올린 후 많은 분들의 보안에 관한 의견을 듣고서 다시 수정하여 올린 것이 이 글입니다.
기본적인 방법은 세션을 파일이 아닌 DB를 통해서 저장한다면 다른 서버에서도 디비 서버에 권한이 있다면 세션정보를 가져올 수 있는 것을 이용했습니다.
디비에서 쿼리할 때 세션키를 키로 해서 자료를 읽어 오는 방법을 썼는데 문제는 이 세션키란 것이 노출된다면 보안의 허점이 생기는 것입니다.(세션키를 키로 해서 쿼리를 하는 것이기 때문) 세션키만 안다면 웬만한 사람은 충분히 뚫고 들어올 수가 있는 것이지요
그래서 생각해 낸 것이 이 세션키가 정상적인 것인지 검증을 할 키를 만드는 것이였습니다.
이 키는 사용자가 가지는 고유한 값(사용자환경,아이피등등)을 조합해서 만들고 이걸 암호화한 데이타를 세션정보와 함께 DB에 저장한 것이지요... 이렇게 할 경우 세션키를 안다고 해도 사용자환경과 똑같은 환경에서 세션이 유효한 시간에 세션키를 가지고 레퍼러를 속이고 들어와야지만 뚫을 수 있는 것이지요...(여기에도 약간의 문제는 있긴 합니다.)
위의 이유 때문에 세션키를 검증할 키를 하나더 만들었던 것입니다.
그럼 질문에 대한 답을 해 드리겠습니다.
1. 세션키를 쿠키가 아닌 url로 넘겨도 상관은 없습니다.
php.ini의 옵션 중에 session.use_trans_sid 란 옵션을 활성화시키면 세션키를 자동으로 url뒤에 붙일 수 있긴 한데 일반사용자에게 세션키를 노출시킬 필요가 없어 쿠키로 조용히(?) 처리하는 것입니다.
2. 제가 정확히 질문이 무슨 뜻인지 이해를 못 하겠습니다.
3. 세션키는 어짜피 쿠키로 구워지는 것이기에 맘만 먹으면 쉽게 얻어낼 수 있습니다. 그래서 검증용 사용자키를 만든 것이고 세션키와 검증용 사용자키가 둘 다 맞지 않으면 뚫기가 힘든 것이죠...
그리고 검증용 키는 항상 변하게 할 수도 있습니다. md5함수를 써서 암호화한다면 검증용 키는 암호화될 때마다 변하겠죠...
그리고 세션키는 그냥 유일한 랜덤 문자열이지만 검증용키는 사용자의 정보를 담은 후 암호화된 문자열입니다.
그리고 위에서도 예기한 것이지만 사용자키를 사용자의 환경 정보나 아이피로 했던 것은 사용자가 A 사이트에서 만들 검증용키와 B 사이트에서 만들 검증용키를 체크하기 위함입니다. 그래서 A 사이트에 있다가 B 사이트에 가면 바뀔 수 있는 값(시간정보)들은 검증용 키를 만들 때 사용하지 않았던 것이죠...
PS. 근데...깨스님...절 어떻게 아시죠??
깨스//
처음 이 방법을 시도할 때는 보안을 크게 신경쓰지 않은 상황에서 기능 구현에 초점을 두고서 만들었습니다.
그러나 첫번째 글을 올린 후 많은 분들의 보안에 관한 의견을 듣고서 다시 수정하여 올린 것이 이 글입니다.
기본적인 방법은 세션을 파일이 아닌 DB를 통해서 저장한다면 다른 서버에서도 디비 서버에 권한이 있다면 세션정보를 가져올 수 있는 것을 이용했습니다.
디비에서 쿼리할 때 세션키를 키로 해서 자료를 읽어 오는 방법을 썼는데 문제는 이 세션키란 것이 노출된다면 보안의 허점이 생기는 것입니다.(세션키를 키로 해서 쿼리를 하는 것이기 때문) 세션키만 안다면 웬만한 사람은 충분히 뚫고 들어올 수가 있는 것이지요
그래서 생각해 낸 것이 이 세션키가 정상적인 것인지 검증을 할 키를 만드는 것이였습니다.
이 키는 사용자가 가지는 고유한 값(사용자환경,아이피등등)을 조합해서 만들고 이걸 암호화한 데이타를 세션정보와 함께 DB에 저장한 것이지요... 이렇게 할 경우 세션키를 안다고 해도 사용자환경과 똑같은 환경에서 세션이 유효한 시간에 세션키를 가지고 레퍼러를 속이고 들어와야지만 뚫을 수 있는 것이지요...(여기에도 약간의 문제는 있긴 합니다.)
위의 이유 때문에 세션키를 검증할 키를 하나더 만들었던 것입니다.
그럼 질문에 대한 답을 해 드리겠습니다.
1. 세션키를 쿠키가 아닌 url로 넘겨도 상관은 없습니다.
php.ini의 옵션 중에 session.use_trans_sid 란 옵션을 활성화시키면 세션키를 자동으로 url뒤에 붙일 수 있긴 한데 일반사용자에게 세션키를 노출시킬 필요가 없어 쿠키로 조용히(?) 처리하는 것입니다.
2. 제가 정확히 질문이 무슨 뜻인지 이해를 못 하겠습니다.
3. 세션키는 어짜피 쿠키로 구워지는 것이기에 맘만 먹으면 쉽게 얻어낼 수 있습니다. 그래서 검증용 사용자키를 만든 것이고 세션키와 검증용 사용자키가 둘 다 맞지 않으면 뚫기가 힘든 것이죠...
그리고 검증용 키는 항상 변하게 할 수도 있습니다. md5함수를 써서 암호화한다면 검증용 키는 암호화될 때마다 변하겠죠...
그리고 세션키는 그냥 유일한 랜덤 문자열이지만 검증용키는 사용자의 정보를 담은 후 암호화된 문자열입니다.
그리고 위에서도 예기한 것이지만 사용자키를 사용자의 환경 정보나 아이피로 했던 것은 사용자가 A 사이트에서 만들 검증용키와 B 사이트에서 만들 검증용키를 체크하기 위함입니다. 그래서 A 사이트에 있다가 B 사이트에 가면 바뀔 수 있는 값(시간정보)들은 검증용 키를 만들 때 사용하지 않았던 것이죠...
PS. 근데...깨스님...절 어떻게 아시죠??
깨스 03-04-30 11:11
제 생각은 이렇습니다. 글로 설명할려니...
세션키의 노출을 예비해 다른 키를 둔다는 것 자체가 별 의미가 없다고 생각되어집니다.
1번 답에 대해서.... 세션키를 URL상으로 노출되는 것은 쿠키에비해 보안상으로 아무런(?) 하자가 없습니다.
네트윅 스니핑 의 경우 URL이나 쿠키나 같다고 보시믄되고.
오히려 쿠키로 저장해 놓을 경우
브라우저가 인터넷상의 특정 페이지나 스크립을 실행시킬때 쿠키값을 노출시킬 위험이 오히려 더 커지고요.
(URL로 넘기는게 가능한데 불필요한 접속점을 두거나, 도메인이 틀릴 경우 각각 틀린 쿠키를 따로 꿔줘야 하는 문제가 또 발생하겠군요.)
2. 근복적으로 하나의 싸이트의 세션의 키의 보안성에서 생각을 하나.
두개의 서버의 세션값을 공유하기 위한 세션키의 보안이나.
별반 차이가 없다는 겁니다. 물론 전혀 차이가 없는건 아니겠지만요
구지 두개의 싸이트의 접속점에 구지 REFERER 체크하고
그곳을 접속점으로 싸이트내 접속이 이루어질 필요는 없다고 생각합니다.
그리고 그 REFERER 을 속이고 세션키를 도용해서 들어오는 사람에게
다른 키 값을 한번 더 체크하게 한다는 자체가 의미가 없다고 생각합니다.
이미 세션이라는 매커니즘 자체가 자료를 서버단에 저장하고 그 유일한 연결매체인
세션키라는 방법을 제공하는데.
구지 또다시 불필요한 오버헤드를 만들며 그 세션키의 무결성을 체크한다는 것 자체가 의미가 없다는거죠.
(세션키는 노출되고 다른 키는 노출이 되지 않나요?
그럼 세션키가 노출이 됐다면 클라이언트 정보는 노출이 없나요?)
차라리 세션 maxlifetime? 인가 이넘을 작게 잡는 것이 효과적이겠죠...
3. 세션키가 쿠키로 꾸어졌다고 맘만 먹으면 쉽게 얻어 내는 것은 아닐텐데요? ㅡㅡ
(네트윅 스니핑을 한다던지, 그 쿠키를 꾼 도메인서버처럼 클라이언트를 속인다던지.)
세션키의 이중보안을 위한 방법론 보다는...
아이디나 패스워드 입력시의 https 를 쓰거나,
전체전인 시스템에 https를 적용하는 근본적인 방법론이 효율적이지 않을려나요?
서버와 클라이언트가 암호화하여 통신하는 어플을 하나 만든것도.... ㅡㅡ
제 생각은 이렇습니다. 글로 설명할려니...
세션키의 노출을 예비해 다른 키를 둔다는 것 자체가 별 의미가 없다고 생각되어집니다.
1번 답에 대해서.... 세션키를 URL상으로 노출되는 것은 쿠키에비해 보안상으로 아무런(?) 하자가 없습니다.
네트윅 스니핑 의 경우 URL이나 쿠키나 같다고 보시믄되고.
오히려 쿠키로 저장해 놓을 경우
브라우저가 인터넷상의 특정 페이지나 스크립을 실행시킬때 쿠키값을 노출시킬 위험이 오히려 더 커지고요.
(URL로 넘기는게 가능한데 불필요한 접속점을 두거나, 도메인이 틀릴 경우 각각 틀린 쿠키를 따로 꿔줘야 하는 문제가 또 발생하겠군요.)
2. 근복적으로 하나의 싸이트의 세션의 키의 보안성에서 생각을 하나.
두개의 서버의 세션값을 공유하기 위한 세션키의 보안이나.
별반 차이가 없다는 겁니다. 물론 전혀 차이가 없는건 아니겠지만요
구지 두개의 싸이트의 접속점에 구지 REFERER 체크하고
그곳을 접속점으로 싸이트내 접속이 이루어질 필요는 없다고 생각합니다.
그리고 그 REFERER 을 속이고 세션키를 도용해서 들어오는 사람에게
다른 키 값을 한번 더 체크하게 한다는 자체가 의미가 없다고 생각합니다.
이미 세션이라는 매커니즘 자체가 자료를 서버단에 저장하고 그 유일한 연결매체인
세션키라는 방법을 제공하는데.
구지 또다시 불필요한 오버헤드를 만들며 그 세션키의 무결성을 체크한다는 것 자체가 의미가 없다는거죠.
(세션키는 노출되고 다른 키는 노출이 되지 않나요?
그럼 세션키가 노출이 됐다면 클라이언트 정보는 노출이 없나요?)
차라리 세션 maxlifetime? 인가 이넘을 작게 잡는 것이 효과적이겠죠...
3. 세션키가 쿠키로 꾸어졌다고 맘만 먹으면 쉽게 얻어 내는 것은 아닐텐데요? ㅡㅡ
(네트윅 스니핑을 한다던지, 그 쿠키를 꾼 도메인서버처럼 클라이언트를 속인다던지.)
세션키의 이중보안을 위한 방법론 보다는...
아이디나 패스워드 입력시의 https 를 쓰거나,
전체전인 시스템에 https를 적용하는 근본적인 방법론이 효율적이지 않을려나요?
서버와 클라이언트가 암호화하여 통신하는 어플을 하나 만든것도.... ㅡㅡ
깨스 03-04-30 11:17
아 글고... PCONNECT 쓰면 connection 이 꽉 차지 않나요? php가 알아서 조절하나.... ㅡㅡ
쯔압. 저는 z*e*r****l 입니다.
아 글고... PCONNECT 쓰면 connection 이 꽉 차지 않나요? php가 알아서 조절하나.... ㅡㅡ
쯔압. 저는 z*e*r****l 입니다.
Fencer 03-04-30 17:09
>>> 깨스
1. URL은 하자가 있습니다.
URL은 컴퓨터에 열어본 페이지 목록으로 기록된다는
아주 원초적인 문제를 갖고 있습니다. ㅡ.ㅡ;
(물론 쿠키도 유효 기간을 브라우저 닫을 때까지로 하지 않으면 문제가 있겠죠.)
그리고 좀 더 근본적으로 매번 처리하기 상당히 귀찮죠. ㅋㅡ.ㅡ;;;
> 브라우저가 인터넷상의 특정 페이지나 스크립을 실행시킬때
> 쿠키값을 노출시킬 위험이 오히려 더 커지고요.
이 부분은 조금 잘못 생각하신 거 같군요.
document.cookie 처럼 document.location 등등이 있으니까요.
오히려 document 속성 중에 URL과 관련된 게 더 많죠. ;
2. 세션키 자체를 변조하지 않는다는 가정하에서
키 값을 하나 더 둔다는 것은 의미가 있습니다.
기본적으로 노출을 피한다기보다는
노출되도 어느 정도 안전한 것을 목표로 하는 게 옳고,
사용자의 모든 정보가 노출된다 하더라도
암호화시 검증용 키를 변하게 만드는 서버 쪽 키가 있는 한,
그리고 암호화 방법 자체가 노출되지 않는 한은
어느 정도 안전하다고 볼 수 있죠.
그러니까 사용자의 모든 것을 알아내고
IP까지 변조해서 들어오지 않는 한은 괜찮을 겁니다.
3. 쿠키 얻어내는 거 쉬워요.
자바스크립트를 모두 막지 않는 한 간단하죠. ;;;
HTTPS가 좋다는 데는 이의가 없지만,
일단 현실은 그렇지가 못 하니까요. ^ ^;
전체에 HTTPS 적용하려면... 서버까지 바꾸어야 하는데. ㅡ.ㅡ;;;
일단 HTTP를 쓰는 현실에서 조금이나마 더 노력해봐야죠. ㅎㅎ;;;
>>> 깨스
1. URL은 하자가 있습니다.
URL은 컴퓨터에 열어본 페이지 목록으로 기록된다는
아주 원초적인 문제를 갖고 있습니다. ㅡ.ㅡ;
(물론 쿠키도 유효 기간을 브라우저 닫을 때까지로 하지 않으면 문제가 있겠죠.)
그리고 좀 더 근본적으로 매번 처리하기 상당히 귀찮죠. ㅋㅡ.ㅡ;;;
> 브라우저가 인터넷상의 특정 페이지나 스크립을 실행시킬때
> 쿠키값을 노출시킬 위험이 오히려 더 커지고요.
이 부분은 조금 잘못 생각하신 거 같군요.
document.cookie 처럼 document.location 등등이 있으니까요.
오히려 document 속성 중에 URL과 관련된 게 더 많죠. ;
2. 세션키 자체를 변조하지 않는다는 가정하에서
키 값을 하나 더 둔다는 것은 의미가 있습니다.
기본적으로 노출을 피한다기보다는
노출되도 어느 정도 안전한 것을 목표로 하는 게 옳고,
사용자의 모든 정보가 노출된다 하더라도
암호화시 검증용 키를 변하게 만드는 서버 쪽 키가 있는 한,
그리고 암호화 방법 자체가 노출되지 않는 한은
어느 정도 안전하다고 볼 수 있죠.
그러니까 사용자의 모든 것을 알아내고
IP까지 변조해서 들어오지 않는 한은 괜찮을 겁니다.
3. 쿠키 얻어내는 거 쉬워요.
자바스크립트를 모두 막지 않는 한 간단하죠. ;;;
HTTPS가 좋다는 데는 이의가 없지만,
일단 현실은 그렇지가 못 하니까요. ^ ^;
전체에 HTTPS 적용하려면... 서버까지 바꾸어야 하는데. ㅡ.ㅡ;;;
일단 HTTP를 쓰는 현실에서 조금이나마 더 노력해봐야죠. ㅎㅎ;;;
깨스 03-05-01 01:54
Fancer 님 얘기가 맞네요
제가 잘못 생각하거나 얘기한 부분도 있지만 그것은 부분적인 것들이고, 어차피 제 얘기의 골격은 아실껍니다.
Fencer 님은 지금 타라우스님이 생각하는 부분들을 이미 구현을 하셨군요.
3. URL + 업로드 + 게시판 + 쿠키 + GET/POST 등등 많겠지만 기본적인 웹과 시스템의 지식 부족으로 생기는 보안구멍이 더 많을 테고... 그런 부분은 기본 아닐까요? 제가 볼때는 저부분에 더 신경 쓰는게 나을꺼 같아요. 여하튼 동의합니다.
그리고 자바스크립에 의한 스니핑을 생각한다면.... HTTPS도 부분적으로 문제가 생기거나 소용이 없겠죠.
그리고 실제로 제 운영경험상... 로그인부분은 Https처리를 해주고, 개인정보나 중요정보 페이지들도 https처리를 해주워도 그리 업렵지 않을꺼 같네요. 접속자들이 버틸만한 서버라면 전체에 적용한다 하여도 문제가 없겠죠.
그건 그렇고... ARP 스니핑 강도가 쌔더군요. 울 회사같은경우 제가 방화벽 접근이 안되기에 필요에 따라 이용할 수 있겠더군요. ㅎㅎ
스위칭일경우 일반 스니핑은 제약사항이 많고... 게이트웨이 역활하는 넘에서 잡아서 필요에따라 썼었는데....
Fancer 님 얘기가 맞네요
제가 잘못 생각하거나 얘기한 부분도 있지만 그것은 부분적인 것들이고, 어차피 제 얘기의 골격은 아실껍니다.
Fencer 님은 지금 타라우스님이 생각하는 부분들을 이미 구현을 하셨군요.
3. URL + 업로드 + 게시판 + 쿠키 + GET/POST 등등 많겠지만 기본적인 웹과 시스템의 지식 부족으로 생기는 보안구멍이 더 많을 테고... 그런 부분은 기본 아닐까요? 제가 볼때는 저부분에 더 신경 쓰는게 나을꺼 같아요. 여하튼 동의합니다.
그리고 자바스크립에 의한 스니핑을 생각한다면.... HTTPS도 부분적으로 문제가 생기거나 소용이 없겠죠.
그리고 실제로 제 운영경험상... 로그인부분은 Https처리를 해주고, 개인정보나 중요정보 페이지들도 https처리를 해주워도 그리 업렵지 않을꺼 같네요. 접속자들이 버틸만한 서버라면 전체에 적용한다 하여도 문제가 없겠죠.
그건 그렇고... ARP 스니핑 강도가 쌔더군요. 울 회사같은경우 제가 방화벽 접근이 안되기에 필요에 따라 이용할 수 있겠더군요. ㅎㅎ
스위칭일경우 일반 스니핑은 제약사항이 많고... 게이트웨이 역활하는 넘에서 잡아서 필요에따라 썼었는데....
Fecner 03-05-01 03:02
>>> 깨스
넵. 님 말씀 이해합니다. ^ ^)/
구현을 해서 쓰고 있긴 하지만,
제가 생각하고 막아놓은 것들에 헛점이 있나 고심하고 있죠.
그래서 TarauS님 글에 관심을 많이 보이고 있습니다.
알고 고민할수록 걱정거리가 늘어난다는... ㅠㅠ;;;
HTTPS를 쓰면 좋겠다...는 생각은 하는데
글쎄요... 저 역시 님 말씀처럼 자바스크립트를 생각한다면
로그인 부분만 써서는 별 소용이 없을 것 같다고 봅니다. ^ ^;
로그인할 때만 쓰면 비번이 노출되지 않는다 뿐이지
로그인 마치고 나면 권한 얻는 게 가능해지니까요. ㅡ.ㅡ;;;
전체 적용하고 싶긴 허나... 역시 현실적인 문제가... ㅎㅎㅎ;
(사용자들도 귀찮다고 하거나 이상하다고 할 걸요. ㅡ.ㅡ+;;;)
윈도우용 스니핑 툴까지 공개적으로 돌아다니고 있으니...
이거 참... 걱정이 태산입니다. ㅡ.ㅡ+++
>>> 깨스
넵. 님 말씀 이해합니다. ^ ^)/
구현을 해서 쓰고 있긴 하지만,
제가 생각하고 막아놓은 것들에 헛점이 있나 고심하고 있죠.
그래서 TarauS님 글에 관심을 많이 보이고 있습니다.
알고 고민할수록 걱정거리가 늘어난다는... ㅠㅠ;;;
HTTPS를 쓰면 좋겠다...는 생각은 하는데
글쎄요... 저 역시 님 말씀처럼 자바스크립트를 생각한다면
로그인 부분만 써서는 별 소용이 없을 것 같다고 봅니다. ^ ^;
로그인할 때만 쓰면 비번이 노출되지 않는다 뿐이지
로그인 마치고 나면 권한 얻는 게 가능해지니까요. ㅡ.ㅡ;;;
전체 적용하고 싶긴 허나... 역시 현실적인 문제가... ㅎㅎㅎ;
(사용자들도 귀찮다고 하거나 이상하다고 할 걸요. ㅡ.ㅡ+;;;)
윈도우용 스니핑 툴까지 공개적으로 돌아다니고 있으니...
이거 참... 걱정이 태산입니다. ㅡ.ㅡ+++
샘 03-05-02 23:25
문제는 클라이언트쪽의 유니크한 값을 모른다는데 있는것 같습니다. 참고하시길...
if (getenv(\＇HTTP_X_FORWARDED_FOR\＇)) {
$ip = getenv(\＇HTTP_X_FORWARD_FOR\＇);
$host = gethostbyaddr($ip);
} else {
$ip = getenv(\＇REMOTE_ADDR\＇);
$host = gethostbyaddr($ip);
}
출처:
http://www.php.net/manual/en/language.variables.predefined.php
//
// Obtain and encode users IP
//
if( getenv(\＇HTTP_X_FORWARDED_FOR\＇) != \＇\＇ )
{
$client_ip = ( !empty($HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇] : ( ( !empty($HTTP_ENV_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_ENV_VARS[\＇REMOTE_ADDR\＇] : $REMOTE_ADDR );
if ( preg_match(\"/^([0-9]+\\.[0-9]+\\.[0-9]+\\.[0-9]+)/\", getenv(\＇HTTP_X_FORWARDED_FOR\＇), $ip_list) )
{
$private_ip = array(\＇/^0\\./\＇, \＇/^127\\.0\\.0\\.1/\＇, \＇/^192\\.168\\..*/\＇, \＇/^172\\.16\\..*/\＇, \＇/^10.\\.*/\＇, \＇/^224.\\.*/\＇, \＇/^240.\\.*/\＇);
$client_ip = preg_replace($private_ip, $client_ip, $ip_list[1]);
}
}
else
{
$client_ip = ( !empty($HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇] : ( ( !empty($HTTP_ENV_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_ENV_VARS[\＇REMOTE_ADDR\＇] : $REMOTE_ADDR );
}
$user_ip = encode_ip($client_ip);
출처 : phpBB
문제는 클라이언트쪽의 유니크한 값을 모른다는데 있는것 같습니다. 참고하시길...
if (getenv(\＇HTTP_X_FORWARDED_FOR\＇)) {
$ip = getenv(\＇HTTP_X_FORWARD_FOR\＇);
$host = gethostbyaddr($ip);
} else {
$ip = getenv(\＇REMOTE_ADDR\＇);
$host = gethostbyaddr($ip);
}
출처:
http://www.php.net/manual/en/language.variables.predefined.php
//
// Obtain and encode users IP
//
if( getenv(\＇HTTP_X_FORWARDED_FOR\＇) != \＇\＇ )
{
$client_ip = ( !empty($HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇] : ( ( !empty($HTTP_ENV_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_ENV_VARS[\＇REMOTE_ADDR\＇] : $REMOTE_ADDR );
if ( preg_match(\"/^([0-9]+\\.[0-9]+\\.[0-9]+\\.[0-9]+)/\", getenv(\＇HTTP_X_FORWARDED_FOR\＇), $ip_list) )
{
$private_ip = array(\＇/^0\\./\＇, \＇/^127\\.0\\.0\\.1/\＇, \＇/^192\\.168\\..*/\＇, \＇/^172\\.16\\..*/\＇, \＇/^10.\\.*/\＇, \＇/^224.\\.*/\＇, \＇/^240.\\.*/\＇);
$client_ip = preg_replace($private_ip, $client_ip, $ip_list[1]);
}
}
else
{
$client_ip = ( !empty($HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_SERVER_VARS[\＇REMOTE_ADDR\＇] : ( ( !empty($HTTP_ENV_VARS[\＇REMOTE_ADDR\＇]) ) ? $HTTP_ENV_VARS[\＇REMOTE_ADDR\＇] : $REMOTE_ADDR );
}
$user_ip = encode_ip($client_ip);
출처 : phpBB
Fecner 03-05-03 04:11
>>> 샘
위에 있는 소스는 보시면 아시겠지만
단지 프락시 서버를 통해 접근할 경우 원래 IP를 찾는 것 뿐입니다.
그리고 그것을 찾아도 고유한 값은 되지 못 합니다.
1. 사설 IP를 통해 여러 대의 컴퓨터가 공인 IP를 공유
2. 한 대의 컴퓨터에서 여러 개의 브라우저 실행
3. anonymous proxy
따라서 참고값이 될 뿐이지 그 이상도 그 이하도 되지는 못 한다고 생각합니다.
그리고 참고로, \＇HTTP_X_FORWARDED_FOR\＇만 있는 것은 아닙니다.
프락시가 넘겨주는 값의 이름은 다른 경우가 종종 있죠.
찾아보시면 몇 가지 나올 것입니다.
>>> 샘
위에 있는 소스는 보시면 아시겠지만
단지 프락시 서버를 통해 접근할 경우 원래 IP를 찾는 것 뿐입니다.
그리고 그것을 찾아도 고유한 값은 되지 못 합니다.
1. 사설 IP를 통해 여러 대의 컴퓨터가 공인 IP를 공유
2. 한 대의 컴퓨터에서 여러 개의 브라우저 실행
3. anonymous proxy
따라서 참고값이 될 뿐이지 그 이상도 그 이하도 되지는 못 한다고 생각합니다.
그리고 참고로, \＇HTTP_X_FORWARDED_FOR\＇만 있는 것은 아닙니다.
프락시가 넘겨주는 값의 이름은 다른 경우가 종종 있죠.
찾아보시면 몇 가지 나올 것입니다.
샘 03-05-03 06:31
HTTP 1.1의 스펙을 살펴보았습니다. 사용자에게 유니크한 값을 부여하는것은 불가능한듯 합니다. 쿠키를 사용하는것이 유일한 방법으로 보입니다. 공유되고 있는 서브넷에서의 쿠키 장난은 막을 방법은 없겠군요.
HTTP 1.1의 스펙을 살펴보았습니다. 사용자에게 유니크한 값을 부여하는것은 불가능한듯 합니다. 쿠키를 사용하는것이 유일한 방법으로 보입니다. 공유되고 있는 서브넷에서의 쿠키 장난은 막을 방법은 없겠군요.
백공열 03-05-07 21:45
mysql_pconnect <--- 요 녀석 땜시 mysql 이 감당을 못할것 같습니다.
java 의 connection Pool 역할을 중간에서 해주는 녀석을 찾았는데.
이걸 사용해야 큰 서비스가 가능할것 같습니다.
http://sqlrelay.sourceforge.net |
|
[본문링크] [함수] 다른 서버, 다른 도메인간 세션 공유 방법 1차 개선
|
|
[1]
|
|
|
|
|
|
코멘트(이글의 트랙백 주소:/cafe/tb_receive.php?no=1173 |
|
|
|
|
|
|
|
|
|
| |
|
|
|
